-
Notifications
You must be signed in to change notification settings - Fork 14.8k
[clang] fix runtime check listing types which can appear in a NestedNameSpecifier #155272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…ameSpecifier Through alias templates, followed by canonicalization, any canonical dependent type can appear in a NestedNameSpecifier. Remove the list as it's not feasible to maintain it. This fixes a regression reported here: #147835 (comment) Since the regression was never released, there are no release notes.
@llvm/pr-subscribers-clang Author: Matheus Izvekov (mizvekov) ChangesThrough alias templates, followed by canonicalization, any canonical dependent type can appear in a NestedNameSpecifier. Remove the list as a practical matter. This fixes a regression reported here: #147835 (comment) Since the regression was never released, there are no release notes. Full diff: https://github.com/llvm/llvm-project/pull/155272.diff 2 Files Affected:
diff --git a/clang/lib/Sema/TreeTransform.h b/clang/lib/Sema/TreeTransform.h
index 1d14ead778446..87550614f645b 100644
--- a/clang/lib/Sema/TreeTransform.h
+++ b/clang/lib/Sema/TreeTransform.h
@@ -5539,21 +5539,10 @@ QualType TreeTransform<Derived>::TransformTypeInObjectScope(
TLB, TL.castAs<DependentNameTypeLoc>(), /*DeducedTSTContext=*/false,
ObjectType, UnqualLookup);
}
- case TypeLoc::Typedef:
- case TypeLoc::TemplateSpecialization:
- case TypeLoc::SubstTemplateTypeParm:
- case TypeLoc::SubstTemplateTypeParmPack:
- case TypeLoc::PackIndexing:
- case TypeLoc::Enum:
- case TypeLoc::Record:
- case TypeLoc::InjectedClassName:
- case TypeLoc::TemplateTypeParm:
- case TypeLoc::Decltype:
- case TypeLoc::UnresolvedUsing:
- case TypeLoc::Using:
- return getDerived().TransformType(TLB, TL);
default:
- llvm_unreachable("unexpected type class");
+ // Any dependent canonical type can appear here, through type alias
+ // templates.
+ return getDerived().TransformType(TLB, TL);
}
}
diff --git a/clang/test/SemaTemplate/nested-name-spec-template.cpp b/clang/test/SemaTemplate/nested-name-spec-template.cpp
index 153f4e2555e3a..0f51a14af9e52 100644
--- a/clang/test/SemaTemplate/nested-name-spec-template.cpp
+++ b/clang/test/SemaTemplate/nested-name-spec-template.cpp
@@ -1,5 +1,5 @@
// RUN: %clang_cc1 -fsyntax-only -verify %s -Wno-c++20-extensions
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c++98 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wno-c++11-extensions -std=c++98 %s
// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
namespace N {
@@ -24,14 +24,7 @@ namespace N {
M::Promote<int>::type *ret_intptr3(int* ip) { return ip; }
M::template Promote<int>::type *ret_intptr4(int* ip) { return ip; }
-#if __cplusplus <= 199711L
- // expected-warning@-2 {{'template' keyword outside of a template}}
-#endif
-
M::template Promote<int> pi;
-#if __cplusplus <= 199711L
- // expected-warning@-2 {{'template' keyword outside of a template}}
-#endif
}
N::M::Promote<int>::type *ret_intptr5(int* ip) { return ip; }
@@ -181,3 +174,15 @@ namespace SubstTemplateTypeParmPackType {
template void f<B>();
} // namespace SubstTemplateTypeParmPackType
#endif
+
+namespace DependentUnaryTransform {
+ template <class T> using decay_t = __decay(T);
+ template <class, class> struct A;
+ template <class T> struct A<T, typename decay_t<T>::X>;
+} // namespace DependentUnaryTransform
+
+namespace DependentSizedArray {
+ template <int V> using Z = int[V];
+ template <class, class> struct A;
+ template <class T> struct A<T, typename Z<T(0)>::X>;
+} // namespace DependentUnaryTransform
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/134/builds/25080 Here is the relevant piece of the build log for the reference
|
Through alias templates, followed by canonicalization, any canonical dependent type can appear in a NestedNameSpecifier. Remove the list as a practical matter.
This fixes a regression reported here: #147835 (comment)
Since the regression was never released, there are no release notes.
Fixes #155260